Methods and systems are known for creating and maintaining backup copies of a primary database which can be used in place of the primary database should the primary database become unavailable. The backup and primary databases are typically maintained on separate systems, to reduce the possibility that a disruptive event will affect both databases. Changes made to the primary database are also applied to the backup database to keep the backup database up-to-date with the primary database.
Maintaining synchronization between a backup database and a primary database can be problematic, especially where there is a failure of the backup system or a communications failure between the primary and backup systems.
Such problems also exist when mirroring database objects maintained with the DB2 database management system available from International Business Machines Corporation of Armonk, N.Y. Any object maintained by DB2 within a virtual storage access method (VSAM) dataset, including tablespaces, tables and indexes can be mirrored. Updates to a DB2 object are logged by DB2. To mirror the original or source object, the log entries can be applied to the mirror or target object so that it is updated with the same actions which were applied to the source object. However, when an object is being mirrored and updates are performed on the mirror object via the DB2 log, there are certain conditions or operations that can result in an invalid mirror object.
One such condition is a "point-in-time," or "partial," recovery. When such a recovery is performed, the data contained in the source DB2 object is refreshed to some point in time other than current. Reasons this would occur include, but are not limited to a data outage and invalid updates by an application program.
A second such condition occurs with a REORG LOG(NO) operation. This operation reorganizes the rows in an object and may in fact relocate them to another part of the object without logging any of the actions carried out in the reorganization.
A third condition which can invalidate the mirror dataset occurs with a LOAD LOG(NO) operation. This operation loads data into a table, over-writing existing data without logging the changes made. This operation is typically performed by a database administrator (DBA) when a table requires more data or in some cases, it is used as a method of recovery.
The aforementioned operations will cause the physical data in the primary, or "source," dataset to be rearranged in a manner which will not be reflected in the DB2 log. As a result, any newly logged data describing changes to the source object cannot be applied to the backup, or "target," dataset without the risk of compromising the data's integrity.
A conventional approach to re-synchronizing the target dataset with the source dataset requires the user to refresh the data in the target dataset using some mechanism to get the data from the source to the target. This may be performed using a copy utility and either a copy of the source or the actual source dataset. In either case, it is a manual intervention that the user needs to perform. Additionally, the user must also somehow determine a new starting point in the DB2 log from which to begin applying log records. In other words, the user is required to identify a point in which the primary and backup databases were synchronized (or "in sync") with each other and then apply to the backup database redo log entries following that point until the backup database is brought back up-to-date with the primary database. Mirroring cannot restart until all of the log records from the predetermined starting point up to the always changing current logpoint are applied.
Another approach is to make, on the backup system, an entirely new copy of the primary database. During such a creation of a new backup database, the backup database will typically not be available for ongoing updates. Because such a process can be rather time consuming, a wide window of time is thus created in which there is no valid backup database available.